home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950528-19950726 / 000146_news@columbia.edu_Thu Jun 15 10:56:14 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA23146
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 18 Jun 1995 06:40:23 -0400
  3. Received: by apakabar.cc.columbia.edu id AA18283
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 18 Jun 1995 06:40:21 -0400
  5. Path: news.columbia.edu!spcuna!citicorp.com!uunet!usc!math.ohio-state.edu!uwm.edu!lll-winken.llnl.gov!osi-east2.es.net!oracle.pnl.gov!mica.inel.gov!pmafire!mars.poci.amis.com!cwis.isu.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: set carrier on, server ##
  9. Message-Id: <1995Jun15.165614.54075@cc.usu.edu>
  10. Date: 15 Jun 95 16:56:14 MDT
  11. References: <3rptu3$nhr@feenix.metronet.com>
  12. Organization: Utah State University
  13. Lines: 95
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <3rptu3$nhr@feenix.metronet.com>, brit@metronet.com (Brit Systems) writes:
  17. > I am using MS-Kermit 3.14. 
  18. > 
  19. > I'm running through some scenarios with
  20. > "set carrier on, server" and what happens when you loose the carrier.
  21. > 
  22. > Here is what I get.
  23. > 
  24. > 1) set carrier on, server, break connection, server exits
  25.  
  26.     Yup. The way it ought to be.
  27.  
  28. > 2) set carrier on, server, start getting file, break connection, 
  29. >     file transfer terminates, server waits forever
  30. >         (at least as long as I wanted to wait).
  31.  
  32.     Correct. The current session terminated. Server mode was
  33.     perpetual.
  34.  
  35. > 3) set carrier on, server 120, start getting file, break connection,
  36. >         file transfer terminates, server waits until timeout then exits.
  37.  
  38.     The very last part needs improvment but basically it's ok.
  39.  
  40. > 4) set carrier on, server 120, start getting very big file, 
  41. >     file transfer completes, server exits since it it past timeout.
  42.  
  43.     Yes, that's what the 120 says, be a server for that long.
  44.  
  45. > Specifically on scenario 2 and 3, is this just me?
  46. > 
  47. > And on a related issue.
  48. > 
  49. > 1) dial someone, set carrier on, start sending file, break connection, 
  50. >     file transfer terminates.
  51.  
  52.     Yup. Correct.
  53.  
  54. > 2) don't call anyone, set carrier on, start sending file,
  55. >     file transfer eventually times out.
  56.  
  57.     Never a carrier then no CD drop state, and hence "no problem."
  58.         Head scratching goes here.
  59.  
  60. > It seems that only connect checks if CD before it starts.
  61. > Send, receive, remote and server don't seem to check CD when they start.
  62. > Is this right?
  63.  
  64.     They don't. They have no idea of the state of the comms channel
  65. so they work so long as bytes can be sent or they run out of retries.
  66. See below for more on this part. Again, modems aren't the only way of
  67. talking.
  68.  
  69. > So if I want to check CD myself, what's the best way.
  70. > "wait 0 cd" seems to work but it prints and ugly "?Timeout message".
  71. > 
  72. > \v(carrier) only says what you set carrier to.
  73. > 
  74. > Is there a \v(cd)? I seem to have seen \CD written but don't know
  75. > how to use it.
  76.     No, there isn't. Maybe there should be, but then modem comms
  77. are only one of many comms channels. In addition, testing for CD involves
  78. firing up the serial port and we may not want that to happen.
  79.  
  80. > Thanks again, for the many times ya'll have helped,
  81. > Robbie Barton 
  82. ----------
  83.  
  84.     Let me be candid on this topic.
  85.     From the beginning of MS-DOS Kermit steps were taken to ensure the
  86. program would not fail because some modem wire wasn't high or low. That
  87. philosophy has carried (sic) forward to the present. Kermit is not dependent
  88. on a modem being present and healthy. Near the release time of MSK v3.14 we 
  89. had a very reasonable request to drop connections when CD vanished, and I 
  90. added code to accomplish that task. We got there but just barely.
  91.     For CD dropping to be a failure one must first have CD asserted,
  92. which explains your "don't call anyone" case. There's room to quibble here.
  93.     From your report we see that matters are slightly muddled regarding
  94. what to do when CD drops. The principal reason for the muddle is CD is
  95. a data link item and ought not penetrate into the higher level software
  96. such as protocol stacks etc. There are many other communications pathways
  97. which do not involve CD. In addition, the Kermit file transfer stack has 
  98. automatic retries on failures (from any cause, reasons for failures are 
  99. normally worthless: failed is failed) and they don't know about the comms
  100. link troubles. So retries occur, and server mode is basically a loop with 
  101. retries (with CD off most of the time, of course), and so on. 
  102.     What can we do about this? Not much right now. I'll have to do the 
  103. doing in the next release and try to add CD sensitivity where possible 
  104. without making a hash of the code. It won't be perfect in the sense that
  105. CD dropping kills the program in a flash, as happens to programs totally
  106. dependent on modems, but it will be better than at present. And we need
  107. to explain a little more carefully what terminating a session means versus
  108. exiting server mode completely.
  109.     Thanks,
  110.         Joe D.